docs: document dynamic sandbox secrets - #25785

[MEDIUM] Custom secrets default to on-demand resolution, but service secrets default to 55-minute caching — no explanation given

Line 331 (added by this PR) states "Dynamic custom secrets resolve on demand by default." However, line 141 (existing) states "Resolved service secrets are cached for 55 minutes by default." These are different commands (sbx secret set-custom vs sbx secret set), so the difference may be intentional, but the PR does not explain why the two commands behave differently. A reader comparing the two sections will likely see a contradiction and be uncertain which behavior applies in their case.

If the difference is intentional (a design choice for sbx secret set-custom), add a brief note explaining why, for example: "Custom secrets are resolved on every use because each host may require a fresh value." If the defaults should match, align the text.

[MEDIUM] NOTE callout wording may confuse users about when OP_ACCOUNT/AWS_PROFILE must be set

The NOTE says to set OP_ACCOUNT or AWS_PROFILE "when you run sbx secret set", then adds that "sbx uses that account or profile whenever it resolves the secret." The second sentence implies the account/profile is persisted at registration — but it doesn't say that explicitly. Users could read the first sentence and conclude they only need the variable at registration time, and be confused if the daemon uses a different account at resolution time (e.g., if the variable isn't persisted and must be present in the daemon's environment too).

Consider clarifying the mechanism — for example: "The value is stored with the secret reference and used by the daemon at every resolution. You don't need to keep the variable set after registration."

[MEDIUM] Custom secrets' on-demand default contrasts with service secrets' 55-minute cache default — asymmetry not called out

Service secrets cache for 55 minutes by default (documented a few sections above); custom secrets resolve on demand by default. Both defaults are correct in their own sections, but no cross-reference or explicit comparison is made. A user who reads only the custom secrets section won't know that the behavior differs from service secrets — they may be surprised by repeated slow lookups on every credential use, or assume the same 55-minute cache applies.

Consider adding a short note such as: "Unlike service secrets, which cache for 55 minutes by default, custom secrets resolve on demand on every use unless you pass --refresh <duration>."